Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-47152: Convert the re module into a package #32177

Merged
merged 10 commits into from
Apr 2, 2022

Conversation

serhiy-storchaka
Copy link
Member

@serhiy-storchaka serhiy-storchaka commented Mar 29, 2022

Lib/re/sre_compile.py Outdated Show resolved Hide resolved
Co-authored-by: Oleg Iarygin <dralife@yandex.ru>
Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to drop "sre_" prefix of module moved into the re package? re.sre_xxx now sounds redundant to me.

Overall, I like the approach!

Would it make sense to put an underscore prefix to "internal" sub-modules like re.sre_compile? For example, rename it to re._compile. asyncio, email and multiprocessing packages don't attempt to hide sub-modules. I don't know what's the best approach here.

The pip project now puts its whole code into a private pip._interal package: https://github.com/pypa/pip/tree/main/src/pip People used to abuse internals which was too easy to access. Now the "pip" package is a front-end only exposing the public API. In the pyperf project, all sub-modules are prefixed by an underscore: https://github.com/psf/pyperf/tree/main/pyperf In my experience, it was a good idea it since the internal API changed many times and I wanted to make sure that people don't use the internal API but only the public and tested API.

@vstinner
Copy link
Member

vstinner commented Apr 1, 2022

The gevent has C extensions (sub-modules) in its gevent package namespace. It might be possible to move the _sre extension as re._sre (or a different name), but the Python build system is not really designed for that. And currently, Linux distributions separate .py files and .so files in two separated directories. I suggest to not change that. It's ok to keep _sre as it is. I don't think that moving it is worth the troubles it would create.

@serhiy-storchaka
Copy link
Member Author

It was my initial approach. Look at changes excluding 3da0b4c.

@vstinner
Copy link
Member

vstinner commented Apr 1, 2022

It was my initial approach. Look at changes excluding 3da0b4c.

If a project currently uses sre_constants, it can use from re import _constants as sre_constants, no? What is the benefits of using keeping the old names?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants